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(57) .Abstract: The sender of a message and any attached data files through a computer network can provide the recipient of such 
a message with a convenient mechanism for replying to the message. For the recipient's convenience, even if the recipient is not a 
registered user of the message deliver}' system of the ser\'er computer system, the sender can permit the recipient to use the same 
level ofsecuriiy available to the sender and can allow the recipient to reply free of charge. In addition, the sender can limit the service 
provided to the recipient with respect to number, addressing, size, formats, security and priority to thereby limit the charges which 
can accrue to the sender by the recipient's reply. The sender can also restrict post-delivery handling by selectively enabling local 
saving, printing, forwarding, and replying to the sender's message by any of the recipients of the message. 
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HTTPS (HyperText Transfer Protocol Secure) protocol. Systems using HTTPS for 
information transfer from person to person have the advantage that security is built into the 
network protocol and few, if any, additional steps by either the sender or recipient are 
required. In addition, the network protocol, i.e., HTTPS, is widely supported by 
commonly available web browsers. Some systems which use HTTPS for electronic, 
person-to-person communication require that both the sender and recipient are registered 
users of the same system for complete, end-to-end security. Registration typically requires 
at least that both the sender and the recipient have established a mechanism by which each 
can be authenticated. As a result, such systems can only be used to communicate with a 
limited class of people since the registered users of any such system represent a limited 
class of people. 

Other systems transferring information using HTTPS require only that the sender 
be a registered user. As a result, the sender can register with the system and send 
information securely to any person who can receive a notification by SMTP/POP e-mail 
which provides instructions for the retrieval of the information through secure channels, 
e.g., HTTPS. This combination of HTTPS person-to-person data transfer coupled with 
SMTP/POP e-mail notification represents the most complete solution to business-ready, 
person-to-person secure communication through public networks. However, such a 
system suffers from the disadvantage that a recipient who is not also a registered user of 
such a system cannot send a reply message back to the sender. As a result, messages 
and/or electronic documents received by the recipient are frequently sent back to the 
original sender (as a reply) or to others (as a forwaided message) through less secure 
chaimels such as SMTP/POP c-mail. 

What is needed is a mechanism by which a sender of information through a 
computer network can exercise significant control regarding post-delivery handling of the 
information by the recipient. 



SUMMARY OF THE INVENTION 

In accordance with the present invention, a sender of a message, which can include 
one or more attached data files, can specify limits on the types of action which can be take 
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Accordingly, transfer of the message to a less secure communications medium, e.g., 
SMTP/POP e-mail, is more difficult. 

In addition to limiting what can be done with the message, by allowing the sender 
to grant the recipient a prepaid reply, the sender can better utilize two-way, person-to- 
person, secure communication through a public network such as the Internet. In addition, 
allowing the sender to set limits on the prepaid reply makes such a prepaid reply a 
practical and useable feature. 

BRIEF DESCRIPTION OF THE DRAWINGS 
Figure 1 is a block diagram of a computer system that includes a server computer 

system coupled to sender and recipient client computer systems through a wide-area 

computer network in accordance with the present invention. 

Figure 2 is a block diagram of the sender computer system of Figure I in greater 

detail. 

Figure 3 is a block diagram of the server computer system of Figure 1 in greater 

detail. 

Figure 4 is a block diagram of the recipient computer system of Figure 1 in greater 

detail. 

Figure 5 is a block diagram of a message database of the server computer system of 
Figure 3 in greater detail. 

Figure 6 is a block diagram of a message of the message database of Figure 5 is 
greater detail. The message includes data specifying post-del iver>' handling parameters in 
accordance with the present invention. 

Figure 7 is a block diagram of prepaid reply parameters of the message of Figure 6 
in greater detail. 

Figure 8 is a block diagram of a prepaid reply in accordance with the present 
invention. 

Figure 9 is a logic flow diagram of the deliver)' of a message with post-delivery 
handling parameters specified in accordance with the present invention. 

Figure 10 is a logic flow diagram of the implementation of post-delivery handling 
parameters of an electronic message in accordance with the present invention. 
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system 102, specifies a message to send to a recipient, e.g., a human user of recipient 
computer system 106. While human users are described in this illustrative example, it is 
appreciated that the sender and/or the recipient can be all or part of one or more computer 
processes executing within sender computer system 102 and/or recipient computer system 
106, respectively. In addition, computer system 102 is referred to as sender computer 
system 102 and computer system 106 is referred to as recipient computer system 106 in 
the context of the illustrative example of a message 502 (Figure 5) sent from computer 
system 102 to computer system 106. Computer systems 102 and 106 are analogous to one 
another; sender computer system 102 is capable of receiving messages in the manner 
described with respect to recipient computer system 106. and recipient computer system 
106 is capable of sending messages in the manner described with respect to sender 
computer system 1 02. 

The message can include generally any data capable of being transferred through 
wide area network 108 and of being stored within server computer system 104. Server 
computer system 104 receives and stores the message and notifies the recipient using 
ordinary SMTP/POP e-mail. The recipient requests transfer of the message from server 
computer system 104 through wide area network 108. 

In response to the request, server computer system 104 sends the message and 
controls post-delivery handling of the message by the recipient in accordance with post- 
delivery handling parameters specified by the sender. For example, server computer 
syf^em 104 can enable or disable post-delivery activities such as printing, locally saving, 
forwarding, and/or replying to the message. In addition, any charges for processing a reply 
message can be charged to the sender even though the reply is sent by the recipient. 

To compose the original message, the sender uses a message composer 204 (Figure 
2) of a message client 202 of sender computer system 102. Message client 202 is all or 
part of one or more computer processes executing within sender computer system 102. 
Message client 202 can be either a thick client or a thin client. If message client 202 is a 
thick client, the computer instructions and data which define the behavior of message 
client system 102 are stored locally within sender computer system 102 and the one or 
more computer processes which collectively define message client 202 are dedicated to 
that task. If message client 202 is a thin client, message client 202 is defined by computer 
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system 104 receives the record from sender computer system 102. In step 904 (Figure 9), 
message receiver 304 (Figure 3) forms a local message record, e.g., message 502 (Figure 
5), and stores the message record in encrypted form in message database 302. Message 
receiver 304 (Figure 3) also receives any attached data files, enciypts the attached data 
files, and stores the encrypted attached files as attached data files 504 (Figure 5), for 
example. 

Message 502 stores the various parameters of the message specified by the sender 
and is shown in greater detail in Figure 6. Message 502 includes fields 602-642 which 
collectively specify a message and its manner of delivery. 

From: field 602 specifies the sender as the entity sending the message. In this 
illustrative embodiment, from: field 602 specifies the POP e-mail address of the sender. 
From: field 602 is not specified by the sender but is automatically set according to the user 
identification used by the sender for authentication with server computer system 1 04 
(Figure 1). 

To: field 604 (Figure 6) specifies one or more recipients of message 502. CC: field 
606 also specifies one or more recipients of message 502 as does BCC: field 608. 
Recipients specified in fields 604-608 all receive message 502. Recipients specified in 
BCC: field 608 are not disclosed to other recipients of message 502. In this illustrative 
embodiment, all recipients are specified in fields 604-608 by POP e-mail addresses. 
Message composer 204 (Figure 2) can include an address book in which the sender 
equates POP e-mail addresses with aliases; however, server computer system 1 04 
processes POP e-mail addresses and message composer 204 substitutes the equated POP e- 
mail addresses for the aliases specified by the sender prior to sending the message record 
to server computer system 104 through wide area network 1 08. 

A subject field 610 specifies a summary description of the subject of message 502 
and is included for the convenience of the sender and the recipients. 

A body field 612 includes the data which is the substantive content of message 
502. Body field 612 can be generally any format but is typically a textual format such as 
ASCII text, rich text format (RTF), and/or HTML. 

Attachment field 614 can include references to one or more attached data files such 
as attached data files 504 (Figure 5). Such data files are specified by the sender and 
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security is selected by the sender, the password or a hash thereof and the hint phrase are 
included in security field 616. 

In account security, all recipients must be registered users of the message delivery 
system of server computer 104 and must authenticate themselves accordingly. For 
example, the recipient must have established an authentication protocol by which the 
recipient is authenticated for access to services provided by server computer system 104. 
The sender is authenticated in the same manner prior to being permitted to compose and 
send message 502. 

The sender can specify any of a number of ways to proceed if one or more 
recipients of message 502 are not registered users of the message delivery system of server 
computer system 104. First, the sender can specify that message 502 is not sent at all if 
any of the recipients are not registered users. Second, the sender can specify that, if any 
recipient is not a registered user, package security is used. If the second option is selected, 
security field 618 includes a password and hint phrase in the manner described above. 
Third, the sender can specify that, if any recipient is not a registered user, that an accoimt 
is created for any and all non-registered recipients. If the third option is selected, the 
sender specifies an initial password for authentication of the recipients and an associated 
hint phrase. The initial password or a hash thereof and the hint phrase are included in 
security field 618. Once a recipient has used the initial password for authentication, the 
recipient can use the same password for authentication for subsequent messages which use 
account security or can change the password of the recipient. In one embodiment, the 
recipient is required to select a new password immediately upon authentication using an 
initial password specified by the sender. 

Notification parameters 620 specify the manner in which the recipient is to be 
notified regarding message 502. By default, notification through SMTP/POP specifies 
only the subject and a private universal resource locator (PURL) by which message 502 
and any attached data files 504 can be retrieved. Such a PURL is described in U.S. Patent 
Application 08/832,784 by Jeffrey C. Smith and Jean-Christophe Bandini entitled 
"Private, Trackable URLs for Directed Document Delivery" and that description is 
incorporated herein by reference. Other information not specific to message 502 can be 
included in the notification e-mail message, such as message retrieval instructions. As a 
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copy of message 502 which can then be sent through less secure channels. Preventing 
printing of message 502 reduces the likelihood that such breaches in security will occur. 

Forward enable field 626 indicates whether the recipient is permitted to forward 
message 502 to someone other than the sender or other recipients of message 502. 
Forwarding message 502 expands the audience beyond that originally specified by the 
sender and such can be prevented by the sender by disabling forwarding of message 502. 
Reply enable field 628 indicates whether the recipient is permitted to reply to message 502 
by sending a message to the sender and/or other recipients of message 502. Disabling a 
reply can be particularly useful if the sender is not a human user but rather all or part of 
one or more computer processes executing within sender computer system 1 02, It is 
possible that such an automated sender is incapable of processing received messages. 
Reply enable field 628 can also specify that reply messages are addressed only to the 
sender and not to other recipients of message 502. 

Prepaid reply parameters 630 specify whether the recipient is permitted to reply to 
message 502 at the expense of the sender. In addition, prepaid reply parameters 630 
specify limits on such a prepaid reply to thereby limit expense to the sender for such a 
reply. Prepaid reply parameters 630 are shown in greater detail in Figure 7. 

Number of replies field 702 specifies the number of times the recipient can reply to 
message 502 at the sender's expense. A value of zero indicates that prepaid replies to 
message 502 are not permitted. 

Reply to: field 704 specifies limits as to whom the prepaid reply can be addressed. 
In this illustrative example, the sender selects one of four (4) limitations. First, the sender 
can specify that only the sender will receive the prepaid reply message. Second, the sender 
can specify that all recipients of message 502 as specified in fields 604-608 (Figure 6) can 
receive the prepaid reply message. Third, the sender can specify that only selected 
recipients specified in fields 604-608 can receive the prepaid reply message. The selected 
recipients can be specified by specifying only one or two of fields 604-608 or by 
specifying individual addresses selected from those specified within fields 604-608. 
Fourth, the sender can specify that the prepaid reply can be sent to anybody. In effect, the 
fourth option allows a prepaid forward message or a prepaid message of any kind. 

Size limit field 706 specifies a limit as to the total size of any prepaid reply 
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recipient is valid. For example, the recipient can be required to enter a date and user 
interface field 714 can include logic, as part of an XML form or as Java™ script 
embedded in an HTML form, which ensures that data supplied by the recipient represents 
a valid date. 

As an example of the use of user interface field 714, user interface field 714 can 
specify an HTML form which includes a survey question, "yes" and "no" radio buttons, 
and a submit button such that the recipient can only response "yes" or "no" to the posed 
question. Such a prepaid reply message can be readily processed automatically since the 
"yes" or "no" response is made unambiguous by the HTML form. Similarly, user interface 
field 714 can include an HTML form with a fixed statement that the document — 
including listed contents — has been received and read and understood by the recipient 
and a "confirm" GUI button. In this way, the sender can provide a kind of 
acknowledgment not otherwise provided by the message delivery system of server 
computer system 104. 

Thus, prepaid reply parameters 630 specify whether a prepaid reply is authorized 
and, if so, specifies limits on the prepaid reply. 

Returning to message 502 (Figure 6), language field 632 specifies a language in 
which message 502 is to be presented to the recipient. While language field 632 does not 
affect presentation of the substantive content of body field 612, supporting text in the 
picsentation of message 502 such as box labels "To:," "From:," and "Subject:" and 
instructions regarding retrieving attached data files are presented in the language specified 
in language field 632. 

Status notification field 634 specifies the manner in which the sender is notified 
regarding processing of message 502. In this illustrative embodiment, two options are 
provided and the sender can select either, both, or neither of the options. In the first 
option, the sender is notified by SMTP/POP e-mail when delivery of message 502 to any 
recipient fails. In the second option, the sender is notified by SMTP/POP e-mail when 
message 502 is successfiilly retrieved and viewed by any of the recipients. Both options 
are implemented independently for each of the recipients specified in fields 604-608. 

Delivery schedule field 636 specifies a time at which message 502 is to be 
delivered. The sender can specify that message 502 is to be delivered immediately or at 
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910-916, the particular recipient processed is referred to as the subject recipient. 

In step 910, message retriever 308 (Figure 3) of server computer system 104 
asynchionously receives a request to view message 502 from the subject recipient. The 
request is received asynchronously in that each recipient receives the notification message 
independently and independently submits the PURL contained in the notification message 
to request message 502 for viewing. Since the PURLs are submitted independently, the 
requests are received by message retriever 308 at various times which are independent of 
one another. 

As described above, the PURL specifies message 502 as the requested message and 
identifies the subject recipient. 

In step 912 (Figure 9), message retriever 308 (Figure 3) conveys the received 
request to message formatter 3 1 0. Message formatter 3 1 0 retrieves message 502 from 
message database 302 and formats message database 302 for display to the subject 
recipient using message reader 408 (Figure 4) of message client 402. If message client 
402 is a thin client, message formatter 310 (Figure 3) builds an HTML document to 
represent message 502. For example, message formatter 3 1 0 includes text in the HTML 
document representing the sender specified in from: field 602 (Figure 6), text representing 
various recipients specified in fields 604-608, text representing the subject specified in 
subject field 610, and the substantive content specified in body field 612. If the content 
represented in body field 612 is a format other than HTML, message formatter 3 10 
converts the format to HTML, preserving as much as the look and feel of the substantive 
content represented in body field 612 as possible in the HTML representation of message 
502. In addition, message formatter 310 includes hypertext links to any attached data files 
504 (Figure 5) specified in attachment field 614 (Figure 6). If, on the other hand, message 
client 402 (Figure 4) is a thick client, message formatter 310 can format message 502 in 
any manner or format recognized by message client 402 (Figure 4). If message client 402 
is a thick client, message client 402 can be configured to recognize practically any format. 

In step 914 (Figure 9), message formatter 310 (Figure 3) includes data specifying a 
user interface according to post-delivery handling parameters of fields 622-630 (Figure 6). 
Such is described more completely below in the context of presentation of message to the 
recipient by message reader 408. A brief example is helpful to understand step 914 more 
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formatted by message formatter 310, including user interface components which 
implement post-delivery handling as specified by the sender, to message client 402 (Figure 
4) of recipient computer system 1 06. 

After all recipients have been processed by the loop of steps 908-91 8, delivery 
processing of message 502 by server computer system 104 according to logic flow 
diagram 900 completes. 

Processing of message client 402 (Figure 4) of the formatted message received 
from message retriever 308 (Figure 3) is shown as logic flow diagram 1000 (Figure 10). 
Message client 402 (Figure 4) is directly analogous to message client 202 (Figure 2) and 
description of either herein is equally applicable to both except where otherwise noted. In 
step 1002 (Figure 10), message reader 408 (Figure 4) of message client 402 enables 
printing of the received formatted message only if the message as formatted specifies that 
printing is enabled. If message client 402 is a thin client, the formatted message includes 
HTML form GUI components, such as a "Print" GUI button, which enable or disable 
specific types of post-delivery actions. For example, if printing is enabled, the formatted 
message includes the "Print*' GUI button, activation of which causes the formatted 
message to be sent to a printer locally attached to recipient computer system 106. If 
printing is disabled, the formatted message includes no such GUI button. 

If, on the other hand, message client 402 is a thick client, message reader 408 
determines that the formatted message specifies that printing is enabled and enables a 
"Print" option of a "File" pull-down menu and/or a "Print" GUI button of a tool bar 
displayed by message reader 408. Alternatively, if message reader 408 determines that 
printing is disabled as specified within the formatted message, message reader 408 
disables the "Print" option and/or the "Print" GUI button. The "Print" option and/or GUI 
button can be shown to be disabled by representing the "Print" option and/or GUI button 
in grey. 

In step 1004 (Figure 10), message reader 408 (Figure 4) enables saving of the 
formatted message to local persistent storage only if the formatted message includes user- 
interface components to effect saving of the formatted message. Step 1004 is generally 
analogous to step 1002. If message client 402 is a thin client, the formatted message 
includes a "Save" GUI button only if message formatter 310 (Figure 3) determined that 



BNSDOCID: -cWO .Ol5069lA2_l_> 



wo 01/50691 



PCT/USOO/35406 



.20- 

presented to the recipient by message reader 408 (Figure 4) in a thin message client 402. 
Inclusion or omission of the "Reply" GUI button from the formatted message indicates 
enabling or disabling, respectively, of replying to the formatted message. 

If, on the other hand, message client 402 is a thick client, the formatted message 
includes data specifying whether replying is enabled and selectively enables or disables a 
"Reply" option in the "File" pull-down menu and/or a "Reply" GUI button on the toolbar 
accordingly in a manner analogous to that described above with respect to steps 1002- 
1006, 

In step 1010 (Figure 10), message reader 408 (Figure 4) enables prepaid replying to 
the formatted message, i.e., sending a reply message to the sender at the sender's expense, 
only if the formatted message includes user-interface components to effect prepaid 
replying to the formatted message. Step 1010 is generally analogous to steps 1002-1008. 
If message client 402 is a thin client, the formatted message includes a "Prepaid Reply" 
GUI button only if message formatter 310 (Figure 3) determined that prepaid reply 
parameters 630 indicate that one or more prepaid replies to message 502 is permitted. 
Whatever GUI components included in the formatted message are presented to the 
recipient by message reader 408 (Figure 4) in a thin message client 402. Inclusion or 
omission of the "Prepaid Reply" GUI button from the formatted message indicates 
enabling or disabling, respectively, of prepaid replies to the formatted message. 

If, on the other hand, message client 402 is a thick client, the formatted message 
includes data specifying whether one or more prepaid replies are enabled and selectively 
enables or disables a "Prepaid Reply" option in the "File" pull-down menu and/or a 
"Prepaid Reply" GUI button on the toolbar accordingly in a maimer analogous to that 
described above with respect to steps 1002-1008. 

In step 1012, message reader 408 (Figure 4) displays the formatted message along 
with the user interface implementation of post-delivery handling effected in accordance 
with steps 1002-1010 (Figure 10). In step 1014, message reader 408 (Figure 4) processes 
the user interface as configured in steps 1002-1010. 

Step 1014 is shown in greater detail as logic flow diagram 1014 (Figure 11). In 
logic flow diagram 1014, the recipient has actuated a GUI component such as a pull-down 
menu option or a GUI button. In the context of logic flow diagram 1014, a GUI button is 
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(Figure 4) determines that the recipient is not a registered member and, when about to 
forward or reply to a message, offers to register the recipient such that the recipient can be 
appropriately charged for the forward or reply message. 

In step 1 112, the recipient uses message composer 404 (Figure 4) to compose the 
forward message in the manner that the original message is composed by the sender. 
Message composer 404 pre-populates fields of the forward message from the original 
message. For example, the subject specified in subject field 610 (Figure 6) is preserved in 
the forward message and prefixed with a forwarded message indication such as "FW:". In 
addition, the substantive content of body field 612 of the original message is preserved 
within the forward message but prefixed with a quotation indication such as ">". Attached 
data files specified by attachment field 614 are similarly attached to the forward message. 
Fields 616-634 are copied fi-om the original message to the forward message except that 
prepaid reply parameters 630 are reset to a default value in which prepaid replies are not 
authorized. Fields 636-640 of the forward message are reset to default values and billing 
code 642 of the forward message indicates that the recipient is to be charged for the 
forward message. The recipient is provided an opportunity to modify any and all of fields 
604-640 using conventional user interface techniques prior to sending the forward 
message. In step 1114 (Figure 1 1), the forward message is sent by server computer system 
104 in the manner described above with respect to the original message. After step 1114, 
processing according to logic flow diagram 1014 completes. 

If, in test step 1 1 10, the user interface action is other than pressing the "Forward" 
button, processing transfers to test step 11 16 in which message reader 408 (Figiu-e 4) 
determines whether the user interface action is pressing of the "Reply" GUI button. If 
reply to the message is not enabled, the "Reply" GUI button is not active or is not present 
and the recipient cannot have pressed the "Reply" GUI button. If the recipient pressed the 
"Reply" GUI button, message reader 408 (Figure 4) builds a reply message in step 1118 
(Figure 1 1) and sends the reply message in step 1 120. It should be noted that the reply 
message is sent by, and charged to, the recipient. Accordingly, the recipient must be a 
registered user of the message delivery system of server computer system 104 to compose 
and send a reply message in steps 1 1 1 8-1 1 20. 

In step 1118, the recipient uses message composer 404 (Figure 4) to compose the 
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(Figure 8), 808, and 810 are analogous to fields 604 (Figure 6), 606, and 608, respectively, 
of message 502. If reply to: field 704 specifies that the prepaid reply message can only be 
sent to the sender of the message to which prepaid reply message replies, message 
composer 404 stores data identifying the sender in field 806 and stores no addresses in 
fields 808-810. For convenience, the message to which prepaid reply message replies is 
sometimes referred to herein as the parent message. If reply to: field 704 specifies that the 
prepaid reply message can only be sent to the sender and all recipients of the parent 
message, message composer 404 stores data identifying the sender in field 806 and copies 
recipient addresses fi-om fields 604-606 of the parent message into field 808 (Figure 8) of 
prepaid reply message 802 and copies the recipient addresses fi-om field 608 to field 810. 
If reply to: field 704 specifies that the prepaid reply message can only be sent to the sender 
and selected recipients of the parent message, message composer 404 stores data 
identifying the sender in field 806 and copies the selected recipient addresses from fields 
604-606 of the parent message into field 808 (Figure 8) of prepaid reply message 802 and 
copies the selected recipient addresses from field 608 to field 810. In any of the preceding 
three c^es, message composer 404 does not permit the recipient to modify fields 806-810 
in composing prepaid reply message 802. However, if reply to: field 704 specifies that the 
recipient can send the prepaid reply to anyone, fields 806-810 are pre-populated in one of 
the manners described above and message composer 404 permits the user to modify the 
contents of fields 806-810. 

In step 1204 (Figure 12), message composer 404 pre-populates subject field 812 
and body field 818. Subject field 812 is analogous to subject field 610, and body field 818 
is analogous to body field 612. If user interface 714 (Figure 7) doesn't specify a particular 
user interface for the substantive content of the recipient's prepaid reply message, message 
composer 404 pre-populates subject field 812 with the contents of subject field 610 
(Figure 6) but prefixed with a reply indication such as "RE:". In addition, message 
composer 404 pre-populates body field 818 with the contents of body field 612 but 
prefixed with a quotation indication such as Message composer 404 permits the 
recipient to modify the contents of subject field 812 and body field 818. However, if user 
interface 714 (Figure 7) specifies a particular user interface, e.g., an HTML form, for the 
recipient's reply, message composer 404 (Figure 4) presents the specified user interface to 
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field 706 (Figure 7) is met by any prepaid reply message. Any violation is reported to the 
recipient and the message is discarded at no cost to the sender. 

In test step 1306, message composer 404 determines whether attachirtg the selected 
data file to prepaid reply message 802 would exceed any size limitation specified in size 
limit field 706 (Figure 7) of the original message, e.g., message 502. If so, message 
composer 404 reports an error to the recipient and does not attach the selected data file to 
prepaid reply message 802 (Figure 8). 

Conversely, if attachuig the selected data file would not exceed the specified size 
limitation, processing transfers to step 1308 (Figure 13) in which message composer 404 
(Figure 4) determines the format of the selected data file. If message client 402 is a thin 
client, message composer 404 may have limited resources for determining the format of 
attached data files. Accordingly, server computer system 104 independently verifies that 
file format limitations specified in attachment fonnats field 712 (Figure 7) are met by any 
data files attached to any prepaid reply message. Server computer system 104 makes such 
a determination by examination of the data contents of such data files. However, even a 
thin client can check some indications regarding file format such as three-letter file name 
extensions which indicate file format. However, since a three-letter extension can be 
changed by a user, server computer system 104 perfonns an independent check of the file 
formats of attached data files. Any violation is reported to the recipient and the message is 
discarded at no cost to the sender. 

In test step 1310 (Figure 13), message composer 404 determines whether the 
format of the selected data file is permitted by the sender of message 502 by reference to 
attachment formats field 712. If the format of the selected data file is not permitted, 
message composer 404 reports an error to the recipient and does not attach the selected 
data file to prepaid reply message 802 (Figure 8). Conversely, if the fonmat of the selected 
data file is permitted, message composer 404 stores a reference to the selected data file in 
attachment field 814 to attach the selected data file to prepaid reply message 802 and 
processing according to logic flow diagram 1300 completes. Thus, message composer 404 
enforces size limitations and format limitations with respect to attached files as specified 
in the original message by the sender. 

If the recipient actuates the user interface for saving a draft of prepaid reply 
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security field 708 (Figure 7) of message 502. 

Prepaid reply message 802 (Figure 8) responds to the parent message which was 
originally sent by the sender and both the prepaid reply message and the parent message 
are charged to the sender. The sender of the parent message is therefore treated as the 
owner of the information contained in both messages. Accordingly, local saving, printing, 
forwarding, and replying to prepaid reply message 802 by sender of the parent message are 
all permitted. In one embodiment, local saving, printing, forwarding, and replying to 
prepaid reply message 802 by any other recipient of prepaid reply message 802 are all 
prohibited. In an alternative embodiment, local saving, printing, forwarding, and replying 
to prepaid reply message 802 by any other recipient of prepaid reply message 802 are all 
controlled by respective fields of the parent message — e.g., save enable field 622, print 
enable field 624, forward enable field 626, and reply enable field 628, respectively, of 
message 502. In this altemative embodiment, a third-party recipient of a prepaid reply 
message had the same handling options with respect to prepaid reply message 802 as with 
respect to message 502. 

Rather than determining the language of the message from data within the message 
itself (e.g., language field 632 — Figure 6 — of message 502), server computer system 
(Figure 3) presents prepaid reply message 802 (Figure 8) using the language specified by 
the parent message, e.g., by language 632 (Figure 6) of message 502. 

Lastly, instead of billing the recipient for sending prepaid reply message 802, 
server computer system 104 bills the account specified in the parent message, e.g., the 
account specified in billing code 642 (Figure 6) of message 502. 

Thus, in accordance with the present invention, the sender can provide the recipient 
with a convenient mechanism for replying to a message fi-om the sender. For the 
recipient's convenience, even if the recipient is not a registered user of the message 
delivery system of server computer system 104, the sender can permit the recipient to use 
the same level of security provided by server computer system 104 available to the sender 
and can allow the recipient to reply fi-ee of charge. In addition, the sender can limit the 
service provided to the recipient with respect to number, addressing, size, formats, security 
and priority to thereby limit the charges which can accrue to the sender by the recipient's 
reply. 
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What is claimed is: 

1 • A method for controlling processing of a message from a sender to a 
recipient, the method comprising: 

receiving, from the sender, data specifying a type of action with respect to 
the message which is permissible for the recipient; and 

associating control data representing the type of action with the message 
such that representation of the message to the recipient enables the type of action 
for the recipient with respect to the message. 

2. The method of Claim 1 wherein the type of action is saving the message to 
persistent storage. 

3. The method of Claim 1 wherein the type of action is printing the message. 

4. The method of Claim 1 wherein the type of action is forwarding the 
message to one or more other recipients. 

5. The method of Claim 1 wherein the type of action is replying to the 
message by sending a second message, which is different from the first-mentioned 
message, to the sender. 

6. The method of Claim 5 wherein any costs associated with the second 
message are charged to the sender. 

7. The method of Claim 6 further comprising: 

receiving, from the sender, limitation data specifying a limitation on the 
type of action; and 

associating the limitation with the message such that the limitation 
enforced. 
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constraints. 

1 8. The method of Claim 1 6 wherein the limitation data include logic for 
validating entered data. 

19. The method of Claim 7 wherein the limitation data specifies an HTML 

form. 

20. The method of Claim 7 wherein the limitation data specifies data in an 
XML fomiat. 

21 . The method of Claim 1 wherein the type of action is enabled for the 
recipient by including with the message data which specifies a user interface by which the 
recipient can invoke the type of action. 

22. The method of Claim 1 wherein the type of action is enabled for the 
recipient by including data which specifies a user interface by which the recipient can 
modify a parameter of the type of action. 

23. A method for controlling processing of a message from a sender to a 
recipient, the method comprising: 

receiving, from the sender, data specifying a type of action with respect to 
the message which is prohibited for the recipient; and 

associating control data representing the type of action with the message 
such that representation of the message to the recipient disables the type of action 
for the recipient with respect to the message. 

24. The method of Claim 23 wherein the type of action is saving the message to 
persistent storage. 

25. The method of Claim 23 wherein the type of action is printing the message. 
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33. The computer readable medium of Claim 30 wherein the type of action is 
forwarding the message to one or more other recipients. 

34. The computer readable medium of Claim 30 wherein the type of action is 
replying to the message by sending a second message, which is different from the first- 
mentioned message, to the sender. 

35. The computer readable medium of Claim 34 wherein any costs associated 
with the second message are charged to the sender, 

36. The computer readable medium of Claim 35 wherein the computer 
instructions are configured to cause the computer to control processing of a message from 
a sender to a recipient by also: 

receiving, from the sender, limitation data specifying a limitation on the 
type of action; and 

associating the limitation with the message such that the limitation 
enforced. 

37. The computer readable medium of Claim 36 wherein the limitation data 
specifies that the second message can only be addressed to the sender. 

38. The computer readable medium of Claim 36 wherein the limitation data 
specifies that the second message can only be addressed to one or more other recipients of 
the first message. 

39. The computer readable medium of Claim 36 wherein the limitation data 
specifies a level of security with which to process the second message. 

40. The computer readable medium of Claim 36 wherein the limitation data 
specifies a priority with which to deliver the second message. 
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50. The computer readable medium of Claim 30 wherein the type of action is 
enabled for the recipient by including with the message data which specifies a user 
interface by which the recipient can invoke the type of action. 

5 1 . The computer readable medium of Claim 30 wherein the type of action is 
enabled for the recipient by including data which specifies a user interface by which the 
recipient can modify a parameter of the type of action. 

52. A computer readable medium useful in association with a computer which 
includes a processor and a memory, the computer readable medium including computer 
instructions which are configured to cause the computer to control processing of a message 
from a sender to a recipient by: 

receiving, from the sender, data specifying a type of action with respect to 
the message which is prohibited for the recipient; and 

associating control data representing the type of action with the message 
such that representation of the message to the recipient disables the type of action 
for the recipient with respect to the message. 

53. The computer readable medium of Claim 52 wherein the type of action is 
saving the message to persistent storage. 

54. The computer readable medium of Claim 52 wherein the type of action is 
printing the message. 

55. The computer readable medium of Claim 52 wherein the type of action is 
forwarding the message to a second recipient, which is different from the first-mentioned 
recipient. 

56. The computer readable medium of Claim 52 wherein the type of action is 
replying to the message by sending a second message, which is different from the first- 
mentioned message, to the sender. 
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message, to the sender. 

64. The computer system of Claim 63 wherein any costs associated with the 
second message are charged to the sender. 

65. The computer system of Claim 64 wherein the message delivery module is 
configured to cause the computer to control processing of a message from a sender to a 
recipient by also:: 

receiving, from the sender, limitation data specifying a limitation on the 
type of action; and 

associating the limitation with the message such that the limitation 
enforced. 

66. The computer system of Claim 65 wherein the limitation data specifies that 
the second message can only be addressed to the sender. 

67. The computer system of Claim 65 wherein the limitation data specifies that 
the second message can only be addressed to one or more other recipients of the first 
message. 

68. The computer system of Claim 65 wherein the limitation data specifies a 
level of security with which to process the second message. 

69. The computer system of Claim 65 wherein the limitation data specifies a 
priority with which to deliver the second message. 

70. The computer system of Claim 65 wherein the limitation data specifies, as a 
maximum permissible size, a maximum pemiissible amount of data that can be used to 
represent the second message. 

71 . The computer system of Claim 70 wherein the maximum permissible 
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modify a parameter of the type of action. 

81. A computer system comprising: 
a processor; 

a memory operatively coupled to the processor; and 
a message delivery module (i) which executes in the processor from the 
memory and (ii) which, when executed by the processor, causes the computer to 
control processing of a message from a sender to a recipient by: 

receiving, from the sender, data specifying a type of action with 
respect to the message which is prohibited for the recipient; and 

associating control data representing the type of action with the 
message such that representation of the message to the recipient disables 
the type of action for the recipient with respect to the message. 

82. The computer system of Claim 8 1 wherein the type of action is saving the 
message to persistent storage. 

83. The computer system of Claim 8 1 wherein the type of action is printing the 
message. 

84. The computer system of Claim 81 wherein the type of action is forwarding 
the message to a second recipient, which is different from the first-mentioned recipient. 

85. The computer system of Claim 81 wherein the type of action is replying to 
the message by sending a second message, which is different from the first-mentioned 
message, to the sender. 

86. The computer system of Claim 8 1 wherein the type of action is disabled for 
the recipient by excluding from the message a user interface by which the recipient can 
invoke the type of action. 
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